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ПРОЕКТНЫЕ ДИАГРАММЫ НА М-\УТ$ЦЧАЕ ГАМСУАСЕ 
И МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ 


Показано, какие проблемы позволяют решать диаграммы на М№-Ибиа! [апдиаде, предназначенные для проек- 
тирования и автоматической кодогенерации программного обеспечения информационных систем. Рассмот- 
рен вопрос связывания проектных диаграмм на М-Ибиа! [апдиаде с диаграммами, моделирующими бизнес- 
процессы, в различных нотациях. 

Ключевые слова: моделирование бизнес-процессов, информационная система, СА$Е-технологии, Мосде|- 
Опуеп епотпеепйпд, визуально-декларативный язык, проектирование программного обеспечения. 


Введение. В области производства программного обеспечения информационных систем (ПО ИС) 
существует ряд проблем, которые приводят, по разным оценкам, к неуспеху от 25 до 35% всех 
проектов. При этом финансовые потери во всем мире составляют миллиарды долларов. Кроме 
того, существуют проблемы сопровождения ПО ИС в средних и крупных организациях, приводя- 
щие к постоянному повышению сложности этого процесса. Организации вынуждены последова- 
тельно увеличивать расходы на поддержку внедренных информационных систем. Такая ситуация 
приводит к тому, что либо расходы на сопровождение информационных систем начинают пре- 
вышать получаемый от них экономический эффект, либо приходится отказываться от таких рас- 
ходов, в результате чего внедренные информационные системы нередко коллапсируют. 
Механизм связывания проектных и аналитических диаграмм. Проблемы ПО ИС во многом 
обусловлены несовершенством используемых при производстве программного обеспечения тех- 
нологий. Современные Моде|-айуеп епдтеейпд технологии (МОЕ-технологии) предназначены для 
улучшения коммуникаций между участниками проекта и для генерации программного кода на ос- 
нове проектных диаграмм. Тяжелые методологии разработки ПО ИС, такие, как КаНопа! УпМеа 
Ргосез5 или Эгисигей Апа!у$!5 апа Бездп Тесйтюце, предполагают широкое использование МПЕ- 
технологий. Однако они повышают стоимость разработки и сопровождения программ из-за необ- 
ходимости затрат отдельно на разработку (поддержку) проектных диаграмм и отдельно на созда- 
ние (изменение) программного кода. Часто это приводит к несоблюдению методологий на прак- 
тике и к расхождению проектных диаграмм и программного кода в процессе эксплуатации. 

По мнению многих исследователей, МОЕ-технологии неэффективны для малых проектов, 
а для средних и больших проектов их эффективность намного ниже ожидаемой. Большинство но- 
вых «гибких» методологий разработки программ (Ехгете Ргодгатиод, Сгу$а!, Адарё\ме ЗоЙмаге 
Реуеортеп@) либо вообще отрицают необходимость МГЕ-технологий, либо допускают их исполь- 
зование только в коммуникативном аспекте. Причина такого положения — невозможность полной 
автоматической генерации программного кода из проектных диаграмм. Существующие нотации, 
например ЕхесицаЫе УМЕ, базирующиеся на стандарте Уп@еа Моде!птд 1апдцаде 2.0 (УМЕ 2.0), 
позволяют генерировать код лишь частично. При этом нотации настолько усложняются, что ста- 
новятся понятными не более чем просто хорошо откомментированная программа. Тем самым их 
коммуникативная ценность сводится к нулю — проектные диаграммы непонятны и бесполезны 
специалистам в предметных областях, а их разработка не менее проста, чем построение кода. 

Стоимость сопровождения ПО ИС также может быть существенно снижена за счет увели- 
чения числа запросов «а4 Нос», выполняемых пользователями без помощи программистов. Сей- 
час эта задача решается технологией интерактивных отчетов (Тпёегасвуе Веро), однако ее воз- 
можности ограничены тем, что расширить исходный набор атрибутов в отчете можно только по- 
средством перестраивания запроса. Последнее, как правило, требует привлечения программи- 
стов. Увеличить число запросов «а Пос», выполняемых пользователями, можно, если упростить 
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гисвиге4 Оицегу Гапдчаде ($01) или, точнее, заменить его на более простой 50! -подобный язык. 
Чтобы не терять выразительной мощности, такой язык должен основываться на нереляционной 
модели данных. Наиболее популярными из постреляционных являются модели, соответствующие 
стандарту ОБесЕ Раба МападетепЕ Сгоир 3.0. Однако этот стандарт не ставит целью упро- 
щение языка запросов, и поэтому работы по созданию декларативных ненавигационных языков 
ведутся вяло. 

Можно выстроить прямую цепочку: проблемы разработки и сопровождения ПО ИС - не- 
достатки тяжелых методологий — недостатки визуальных нотаций (УМЕ 2.0 или Тщедгаеа 
Рейт оп) — недостатки моделей данных (реляционной и объектных). Эта цепочка демонстрирует, 
что для решения практических проблем необходимо последовательное решение задач, начиная с 
разработки новой модели данных. 

В работе [1] представлена М-модель данных, на основе которой разработаны декларатив- 
ный язык запросов М-ОебагаН уе [апдиаде [2] и визуально-декларативный язык проектирования 
М-\М ва! Гапдцаде (ММГ) [3]. Методы создания нормализованных (неизбыточных) проектных диа- 
грамм на языке ММ предложены в работах [4, 5]. Таким образом, разрабатывается принципиаль- 
но новая МОЕ-технология, способная конкурировать с существующими: 

— за счет сокращения цикла производства и внесения изменений в ПО ИС посредством 
полной автоматической кодогенерации структур данных и бизнес-логики; 

— повышения коммуникативного эффекта благодаря более простому и понятному визуаль- 
но-декларативному языку моделирования; 

— снижения числа обращений в процессе эксплуатации ПО ИС вследствие использования 
более простого языка запросов, позволяющего большую часть запросов «а Нос» строить без 
вмешательства программистов. 

Новая технология позволяет снизить стоимость и риски процессов проектирования и раз- 
работки ПО ИС. Однако для информационных систем существенны и риски, связанные с анализом 
предметной области. К таковым, прежде всего, можно отнести следующие: 

— разработанная и уже внедренная система решает лишь часть задач, для которых была 
предназначена; 

— разработанная система не соответствует ожиданиям заказчика в том смысле, что реша- 
ет не те проблемы, которые важны для него в первую очередь; 

— разработанная и внедренная система не соответствует принятым у заказчика техноло- 
гиям обработки данных и документов и поэтому не используется на практике. 

Перечисленные риски являются следствием несоответствия реализованного в системе 
функционала имеющимся у заказчика бизнес-процессам. Это несоответствие может возникать по 
нескольким причинам. Как правило, у заказчика отсутствует четкое представление о том, какие 
задачи должна решать информационная система, или же нет согласованного представления об 
этом на различных уровнях исполнения. Поэтому требования к ПО ИС могут формулироваться 
расплывчато, а иногда и противоречиво. 

Попытка формализовать требования заказчика только посредством технического задания 
(Т3) малоэффективны. Они часто приводят лишь к тому, что у исполнителя появляется возмож- 
ность оправдаться: что в задании указано, то и сделано. Но почему не указали то, что было нуж- 
но? Или не так изложили? Потому что техническое задание -— это не тот документ, по которому 
легко понять, какие потребности заказчика будут реализованы, а какие нет. Структура этого тек- 
стового документа не дает целостного представления, позволяющего в дальнейшем углубиться в 
детали. А самое главное, ТЗ на информационную систему не имеет прямых связей с тем, как и что 
делается на автоматизируемом предприятии. Иными словами, нет прямой связи между планируе- 
мым к реализации функционалом системы и принятыми на предприятии бизнес-процессами. Это и 
является основной причиной того, что некоторые бизнес-процессы «выпадают» из автоматиза- 
ции, затрагиваются лишь частично или автоматизируются не так, как представляется заказчику. 


1025 


Физико-математические науки 








Для исключения подобных ситуаций ТЗ должно разрабатываться не на устных положениях 
заказчика, а на основе результатов анализа бизнес-процессов. При этом результаты такого ана- 
лиза должны формализовываться в виде, доступном для легкого понимания и заказчиком, и ис- 
полнителем. Инструментом такой формализации давно стали САЗЕ-технологии. Как правило, для 
моделирования бизнес-процессов используются нотация Ваа Но\м/ Оадгат (ОЕО), функциональ- 
ные диаграммы ТРЕРО, диаграммы активности (Асё\уКу ОГадгат) УМЕ 2.0 или диаграммы в нотации 
Визтез$ Ргосез5 Моде!тда МоаНоп (ВРММ). 

Проектные диаграммы на языке ММ для моделирования бизнес-процессов использоваться 
не могут. В отличие от либерального стандарта УМЕ, где почти каждый элемент языка может 
участвовать в моделировании всего, что угодно, ММЁ утверждает строгую стилистику: каждый 
элемент языка имеет только одно назначение и не может интерпретироваться различными спосо- 
бами. 

Тогда каким образом осуществить переход от модели бизнес-процесса к проектным диа- 
граммам? Необходимо связать элементы диаграмм, описывающих бизнес-процессы с элементами 
проектных диаграмм на языке ММ. 

Сначала покажем, как произвести связывание проектных диаграмм с нотацией ОРО, затем 
обобщим его для случаев ТРЕРО, Асёуку Г/адгат и ВРММ. М№-модель данных, на которой основан 
язык ММ, дает для этого удобный инструмент. Она постулирует, что атрибут является функцией, 
определенной на множестве объектов, причем, способы задания этой функции могут быть раз- 
личными. Атрибут является исходным, если его значения задаются перечислением. Атрибут явля- 
ется расчетным, если его значения определяются последовательностью операций (формулой). 
Таким образом, в М-модели не делаются принципиальные различия между исходными и расчет- 
ными данными, а вычислительные процессы декларативно определяются в расчетных атрибутах. 

Обозначим отношение информативности /<=Е хх, где Г — множество атрибутов, Х — мно- 
жество объектов (в том числе классов). Обозначим символом 35 с индексом множество атрибутов, 
определенных на классе х с тем же индексом или в его категориях. Согласно [1], атрибут /; может 
быть информативен на классе х‚, если: 

— определен на этом классе или его категории 

Де ЗЕ, х)ЕГ 
— определен на классе, от которого он наследует, или его категории 
ДЕЗ, хех->(р, х)ЕБ 
— определен на классе или категории класса, который наследует от него 
ДЕЗ, хх, хде. 

Введем отношение композиционной информативности ГоРхх. Атрибут { композиционно 
информативен на классе х‚, если: 

— информативен на этом классе 

(Г, х)ЕЕЫ(Е, х)ЕГ; 

— композиционно информативен на классе х,„ и класс х; может быть связан через опера- 
цию композиции с классом х; 

(1, х)ЕГ, Э(®, хде, что ехусх-Ы(, х)ЕГ.. 

Обозначим множество атрибутов, композиционно информативных на произвольном классе 
х, символом 4 с таким же индексом, как у класса: 

4/7 хде! 

Назовем потоком и обозначим символом 5 подмножество произвольного множества Ч... 

Множество потоков 5 определим как 








5=4{5/Ях, что Ей. 
В проектной диаграмме на языке ММЕ потоку может соответствовать некоторое множество 
атрибутов связанных между собой классов. 
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Сотрудник: Е у Склад: ЕпШу 
Табельный_Помер: Ииезег Префикс: сВак(2) 
Фамилия: уагсваг(128) Номер: Пиеоег 





Имя: уагсваг( 64.) 




























































































Правовая форма: Абзгасе Отчество: уагсВаг(72)) 
Код_ ОКОПФ: Пиеоег Группа_НДС: Абзтаси 
Наименование Формы: уагсваг(512)) Склад у” Инвентаризации | аим Группы: уагсваг(512) 
Сокращение Формы: уагсваг(24)) Инвентаризация: ЕпШу НДС: доче 
Ответственный -> Дата: Рае 
Инвентаризации Заключение: уагсаг(1024) 
2% 2% 
Контрагент: Е пу Поставщик -> Накл постав Накладная: Еву Товар: Абзас 
ИНН: сфак(18) Номер: сВаг(16) Код: сфаг(24) 
Наименование: уагсваг(256) Плателыник >Накл_плат Дата: 4 Наименование: уагсфаг(256) 








Цена: доче 
Сумма = Зшт(Стоим с НДС) 










































































Получатель -> Накл_получ 
Ед_Измерения -> Товары 
Адрес Котрагент г 
Товар Спец_Накл 
Адрес: ЕйШу Спецификация _Накладной: Епу Единица Измерения: Афзгас 
Почтовый_код: сваг(12) Порядковый Номер: Пиеоег Код ОКЕИ: сваг(б) 


Количество: доц е Наименование: уагсваг(512) 


Стоимость = Количество * Товар.Цена Краткое _Наим: уагспаг(48) 
Стоим_с_НДС = Стоимость * 

















(1 + Товар.НДС) 
































Фрагмент предметной области «Складской учет» 


В приведенном на рисунке примере можно выделить следующие множества композицион- 
но информативных атрибутов: 


Ч накладная = ЧФ Спецификация Накладной = ЧФ контрагент Ч правовая Форма = 
=Чтовар — Ч грулна_ндс — Ч Адрес ЧФ диница_ Измерения = 
{Накладная.Номер, Накладная.Дата, Накладная.Сумма, Специфика- 
ция_Накладной.Порядковый_Номер, Спецификация _Накладной.Количество, 
Спецификация _Накладной.Стоимость, Спецификация_Накладной.Стоимость_с_НДС, 
Контрагент.ИНН, Контрагент.Наименование, Правовая _Форма.Код_ ОКОПФ, 
Правовая Форма.Наименование Формы, Правовая_Форма.Сокращение Формы, Товар.Код, 
Товар.Наименование, Товар.Цена, Группа _НДС.Наим_Группы, Группа _НДС.НДС, 
Адрес.Почтовый_Индекс, Единица_Измерения.Код_ОКЕИ, Единица_Измерения. 


Наименование, Единица_Измерения.Краткое Наим}, 


Ч сотрудник — Ч Склад — Ч инвентаризация —: 
{ Сотрудник.Номер, Сотрудник.Фамилия, Сотрудник.Имя, Сотрудник.Отчество, 


Склад.Префикс, Склад.Номер, Инвентаризация.Дата, Инвентаризация.Заключение}. 
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Поток, непосредственно формирующий товарную накладную, как документ!, выделяется 
как подмножество Чн„кладная (ИЛи любого равного ему множества композиционно информативных 
атрибутов): 

5 ={Накладная.Номер, Накладная.Дата, Накладная.Сумма, Специфика- 
ция_Накладной.Порядковый_Номер, Спецификация _Накладной.Количество, 
Спецификация _Накладной.Стоимость, Спецификация_Накладной.Стоимость_с_НДС, 
Контрагент.Наименование, Правовая Форма.Сокращение Формы, Товар.Код, 
Товар.Наименование, Товар.Цена, Адрес.Почтовый_Индекс, 
Единица_Измерения.Краткое Наим}. 

Определение потока полезно не только для рассматриваемого вопроса, но еще и фор- 
мально определяет множество атрибутов, значения которых могут быть получены в одном запро- 
се на языке №-ОБеагаНуе [апдчцаде. Результатом любого запроса могут быть значения атрибутов 
только одного потока. 

Нотация ОЕРО предоставляет для моделирования бизнес-процессов четыре механизма: 
процессы, потоки данных, хранилища данных и внешние сущности. Очевидно, что ни процессы, 
ни внешние сущности нельзя сопоставить с введенным выше понятием потока. Нельзя с ним со- 
поставить и понятие хранилища данных — последнее более узко, поскольку определяет только 
сохраняемые исходные данные. Остаются потоки данных, которые определяются как механизмы, 
используемые для моделирования передачи информации (или даже физических компонентов) из 
одной части системы в другую. 

С одной стороны, понятие потока данных в ОЕО кажется более широким, чем понятие по- 
тока в смысле М№-модели, поскольку позволяет моделировать и физические компоненты. Тем не 
менее необязательно связывать все потоки данных с проектной диаграммой на языке ММ -— 
достаточно ограничиться только теми из них, которые моделируют передачу информации. 
Общепринятый подход предполагает спецификацию таких потоков с помощью, например, форм 
Бэкуса — Наура (БНФ). Однако такая спецификация не имеет большой практической ценности - из 
БНФ нельзя получить ни код, ни структуры данных. Поэтому предлагается специфицировать по- 
токи данных ОЕО с помощью потоков М№-модели. Причем одному потоку ОЕО соответствует строго 
один поток №-модели. В контексте проектных диаграмм на языке ММ, потоку данных соответству- 
ет множество атрибутов связанных между собой классов. 

Предлагаемый подход позволяет осуществить гармоничный переход от диаграмм, модели- 
рующих бизнес-процессы, к диаграммам на языке ММЕ, из которых генерируются структуры дан- 
ных и программный код. Иными словами, связывание потоков данных с потоками М-модели вы- 
страивает мостик между анализом и остальными фазами проекта. 

В стандарте ТОЕРО [6] бизнес-процессы моделируются с помощью функциональных диа- 
грамм. В этой нотации представлены следующие элементы: работы, входы, выходы, управление, 
механизмы и вызовы. Потокам М-модели здесь соответствуют только входы и выходы. Вход — ма- 
териал или информация, которые используются или преобразуются работой для получения ре- 
зультата (выхода). Выход — материал или информация, которые производятся работой. Как и в 
случае с ОЕО, входы и выходы могут описывать материальные объекты. Но, как и в предыдущем 
случае, потоки М-модели могут специфицировать только те входы и выходы, которые моделируют 
информационное взаимодействие. 

Использование для моделирования бизнес-процессов АсЧуКу [ГЛадгат стандарта 
УМЕ 2.0 [7] хотя и ненормативно, но на практике встречается нередко. Если отбросить такие эле- 
менты АсИ\Ку Птадгат, как состояния, активности (действия), дорожки, ворота и объекты, то для 
связи с потоками М-модели остаются потоки управления (переходы). Специфицируемый поток 
должен интерпретироваться как информационный и передаваться от одной активности к другой. 

Нотация ВРММ [8] для моделирования бизнес-процессов в настоящее время является наи- 
более перспективной. Она поддерживается концерном ОМС и, кроме того, встроена во многие 





1 Из примера в данном случае исключены банковские реквизиты и адреса контрагентов, а также основание и сведения о 
товарно-транспортной накладной. 
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коммерческие системы электронного документооборота или управления контентом. Таким обра- 
зом, описания бизнес-процессов в нотации ВРММ используются не только для построения инфор- 
мационных систем, но и для четкого задания правил и ограничений электронного документообо- 
рота. 

Нотацию ВРММ можно рассматривать как некое расширение АсёуКу Гладгат. Однако она, 
в хорошем смысле, сужает «свободу творчества» аналитика, накладывая жесткие ограничения на 
интерпретацию элементов. Как и в АсЁ\Ку ПО’адгат для моделирования бизнес-процессов, здесь 
можно использовать состояния, активности (действия), ворота и дорожки. В качестве объектов 
взаимодействия используются ассоциации, потоки взаимодействия и потоки сообщений. Посколь- 
ку последние трактуются как механизмы, показывающие передачу сообщений между участниками 
бизнес-процессов, для их спецификации можно использовать потоки №-модели (см. таблицу). 


Спецификация элементов диаграмм, моделирующих бизнес-процессы 
атрибутами проектных диаграмм на языке ММ 




















Нотация Элемент Примечание 
Рафа Ном/ Огадгат (РЕО) Потоки данных Специфицируются потоки, ’модели- 
Е 6 рующие передачу информации. 
ГпкедгаНоп Бейпоп Гог Рипсбоп Моде|- | Входы и выходы Спецификации входов и выходов 
тд (ТРЕРО) Ум— принципиально не отличаются и вы- 
пои полняются аналогично спецификациям 
потоков данных. 
Упшед Моде!та ЁГапдцаде: АсёуКу Гла- | Потоки управления (переходы) Специфицируются только помеченные 
дгат У потоки управления, обозначающие 
передачу данных (документов). 
Визтез5 Ргосез5 Моде!та  МобаНоп | Потоки сообщений Могут специфицироваться все потоки 
«ММ > сообщений. 











Заключение. По результатам проделанной работы можно сделать вывод, что проектные диа- 
граммы на языке МУЁ связываются с диаграммами, моделирующими бизнес-процессы посредством 
информационных объектов взаимодействия. Эти объекты специфицируются с помощью потоков 
№-модели, которые представлены на проектных диаграммах в виде некоторых множеств атрибу- 
тов (см. таблицу). 
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